Systems for accomplishing business transactions electronically are becoming increasingly widespread, partly because of the advent of global computer networks such as the Internet, and partly because of the evolution and maturity of public key cryptography, which enhances the security of such commerce. The application of public key cryptography to electronic commerce has been heretofore envisioned in documents such as Recommendation X.509 of the International Telecommunications Union (ITU, formerly CCITT).
To use secure electronic commerce according to the conventional methods, each user has a pair of related keys, namely a private key and a public key. A public key is simply a value (generally a number), and has no intrinsic association with anyone, including the person whose message it is to authenticate. Widespread, commercial use of digital signatures requires reliable information associating public keys with identified persons. Messages of those identified persons can then be authenticated using the keys.
Digital signature certificates meet this need. These certificates are generally issued by trusted third parties known as certification authorities (CAs) and they certify (1) that the issuing certification authority has identified the subject of the certificate (often according to specifications delineated in a certification practice statement), and (2) that a specified public key (in the certificate) corresponds to the a private key held by the subject of the certificate. A structure for public-key certificates is included in the X.509 standard cited earlier. The content of a certificate is often specified in a statute or regulation. A typical X.509 certificate has the format:
X.509 CertificateVersion NumberCertificate Serial NumberAlgorithm IdentifierCertificate IssuerValidity PeriodSubscriberSubscriber's public keyinformationSignature of Issuer
Generally, a valid term is specified in the certificate. The certificates become invalid for its expiration. In addition, the invalid certificates may include any certificate which:                (1) has been revoked (i.e., have been declared permanently invalid by the certification authority which issued the certificate); and        (2) is suspended at the time of reliance (i.e. has been declared temporarily invalid by the certification authority which issued the certificate).        
Suspending and/or revoking certificates are an important means of minimizing the consequences of errors by the certification authority or subscriber. Depending on applicable legal rules, a certification authority may avert further loss due to inaccuracy in the certificate by revoking it. A subscriber can revoke a certificate to prevent reliance on forged digital signatures created using a compromised, e.g., lost or stolen, private key. Certificates which become invalid by revocation are generally listed in a certificate revocation list (CRL), according to ITU X.509. Suspension, or temporary invalidation, was not contemplated in ITU X.509, and may or may not be included in the CRL. Certificates which become invalid by virtue of their age need not be listed in a CRL because each certificate contains its own expiration date.
As a practical matter, the conventional CRL-based system works as follows. Before a subscriber can create a verifiable digital signature, the signer must arrange for a certification authority to issue a certificate identifying the subscriber with the subscriber's public key. The subscriber receives back and accepts the issued certificate, and then creates digital signatures and attaches a copy of the certificate to each of them. When the other party to a transaction receives such a digital signature, the other party must check with the certification authority, generally via its on-line database, to determine whether the certificate is currently valid. If so, and if the digital signature can be verified by the public key in the certificate, the party is usually in a strong position to rely on the digital signature.
Modern e-business typically work or will work on the open Internet and need to access CRLs from multiple CAs as users may use any existing CAs of their choice. But different CAs may use different CRL distribution mechanisms, some of which are very complicated. This demands that the application developers have rich knowledge of these CRL distribution mechanisms. In addition, some CAs may change their CRL distribution mechanisms from time to time, which may impose significant change on the way in which applications can access their CRL.
Further, CRL online distribution, such as via a directory server, is adopted by some CAs. An application can down load these CRLs when needed. But real time access to CRL may be very expensive and not necessary for most application. In addition, the CRLs downloaded and parsed by one application can't be shared by others, which is also a waste of system resources.